Βασικές οδηγίες και Παραδοτέα 2

Φάση Ι - Ανάθεση - ΟΔΕ - Ενημέρωση εμπλεκομένων Υπουργείων

Ι.1 Εργασίες υποστηρικτικές της ανάθεσης

Το πρώτο βήμα για την ανάληψη της δράσης είναι η συμπλήρωση της σχετικής εγγραφής στον κατάλογο των ΨΔ.

Ταυτόχρονα συμπληρώνεται μία σύντομη περιγραφή της ΨΔ απο τον υπεύθυνο του έργου που περιλαμβάνει τις πληροφορίες του Παραρτήματος ΙΙ. Το συγκεκριμένο αποτελεί πρόπλασμα της Σύνοψης.

Ο Αναλυτής του έργου λαμβάνει όλες αυτές τις πληροφορίες, καθώς και οποιαδήποτε περαιτέρω πληροφορία σχετικά υφίσταται προφορικά ή με άλλες επικοινωνίες. Αυτό περιλαμβάνει, ταυτόχρονα, και επαφές με όλα τα εμπλεκόμενα στελέχη, όπως οι:

• Υπεύθυνος από Υπουργείο ΨΔ
• Υπεύθυνος αρμόδιου Υπουργείου
• Υπεύθυνος ΕΔΥΤΕ

Ι.2 Ενημέρωση εμπλεκομένων αρμόδιου Υπουργείου

Απαραίτητη προϋπόθεση πριν την οποιαδήποτε εκκίνηση ή άλλη κίνηση είναι η ενημέρωση των αρμοδίων στελεχών του/ων εμπλεκόμενου/ων ή αρμόδιου/ων Υπουργείων.

Αυτό αποτελεί καθήκον του Αναλυτή ο οποίος συμβουλεύεται τον ειδικό κατάλογο αρμοδίων και ενημερώνει κατά σειρά :

• Τον Υπεύθυνο Ψηφιακών Δράσεων του Υπουργείου Ψηφιακής Διακυβέρνησης,
• Τον αρμόδιο Διευθυντή του τμήματος του φορέα που αφορά η δράση,
• Τα αρμόδια στελέχη της Διεύθυνσης Ηλεκτρονικής Διακυβέρνησης του φορέα.

Και όποιον άλλον υποδείξουν τα αρμόδια στελέχη του Υπουργείου Ψηφιακής Διακυβέρνησης.

Ι.3 Δημιουργία ΟΔΕ (Ομάδα Διοίκησης έργου)

Απαραίτητο βήμα αλλά για το οποίο φροντίζει ο Business Owner. Ο Αναλυτής συμμετέχει στην ΟΔΕ.

Φάση ΙΙ - Προκαταρκτικές εργασίες - Σύνοψη

Ο Αναλυτής κάνει τις πρώτες ενέργειες προετοιμασίας και τη βασική καταγραφή. Παραδοτέο της Φάσης αυτής είναι η Σύνοψη.

Σκοπός της Σύνοψης είναι

• η διασφάλιση ενιαίας, κοινής αντίληψης όλων των εμπλεκομένων για το στόχο της ΨΔ,
• η τεκμηρίωση της αναγκαιότητας της και
• η συλλογή σε συνοπτική μορφή αρχικών πληροφοριών που θα υποστηρίξουν την περαιτέρω έρευνα και ανάλυση.

Δύο βασικές ενέργειες

ΙΙ- 1 Προκαταρκτική έρευνα - Desk research

Συλλέγονται όλες οι πληροφορίες που είναι δυνατόν να συλλεχθούν με έρευνα μέσω διαδικτύου ή τηλεφωνημάτων/ επισκέψεων σε υπηρεσίες.

ΙΙ-2 Προκαταρκτική έρευνα - Αρχικές συνεντεύξεις

Πραγματοποιούνται αρχικές συνεντεύξεις με όσα εμπλεκόμενα άτομα μπορούν να φωτίσουν το ζήτημα ώστε, μαζί με τα λοιπά στοιχεία που έχουν συλλεγεί, να ολοκληρώσουν την αρχική συγκέντρωση βασικών πληροφοριών για το σκοπό της ΨΔ. Ιδιαίτερα προσεγγιζονται οι power users των πληροφοριακών συστημάτων ή/και των σχετικών διαδικασιών.

ΙΙ-3 Προκαταρκτική έρευνα - Καταγραφή εμπλεκομένων πληροφοριακών συστημάτων

Καταγράφονται όλα τα εμπλεκόμενα πληροφοριακά συστήματα, τουλάχιστον όπως στο υπόδειγμα του Παραρτήματος ΙΙΙ.

Παραδοτέο

Οι ενέργειες αυτές, καθώς και όσες άλλες κρίνει ο Αναλυτής απαραίτητες, αποσκοπούν στο να συμπληρωθεί το παραδοτέο Σύνοψη, το οποίο πρέπει να δίνει απαντήσεις τουλάχιστον στα εξής:

• Το πρόβλημα (συνοπτικά)
• Συνοπτική περιγραφή της υπό εξέταση λύσης
• Εμπλεκόμενοι φορείς και συστήματα Και να συλλεγούν μια σειρά σημαντικές πρακτικές πληροφορίες που θα διευκολύνουν την περαιτέρω μελέτη. Τέλος, μια πρώτη εκτίμηση χρονοδιαγράμματος και κόστους, καθώς και πιθανός τρόπος υλοποίησης (εσωτερική υλοποίηση, ανάδοχος, κ.λ.π.).

Παραδοτέο: Σύνοψη όπως σε Παράρτημα ΙΙΙ
Εκτιμώμενος χρόνος: 1 εβδομάδα

ΙΙ-4 Προκαταρκτικές εργασίες για διαλειτουργικότητες

Δεδομένου ότι ορισμένες διαλειτουργικότητες απαιτούν πολύ χρόνο υλοποίησης σκόπιμο είναι να ακολουθείται η εξής πρακτική που είναι καθ’ υπόδειξιν της ΓΓΠΣΔΔ.

• Καταγράφονται έγκαιρα όλες οι απαιτούμενες διαλειτουργικότητες. Δεν έχει σημασία αν κατά την πορεία της ανάλυσης τροποποιηθούν.
• Εξετάζεται αν οι απαιτούμενες διαλειτουργικότητες υφίστανται ήδη στο ΚΕΔ.
• Εφόσον η ανάγκη καλύπτεται γίνεται σχετική αίτηση όπως φαίνεται στις σχετικές οδηγίες που υπάρχουν στον σύνδεσμο του ΚΕΔ. ΑΠΟ ΤΟΝ ΦΟΡΕΑ ΤΟΥ ΕΡΓΟΥ
• Εφόσον η ανάγκη δεν καλύπτεται γίνεται νέο αίτημα αλλά πάλι από τον ΦΟΡΕΑ ΤΟΥ ΕΡΓΟΥ.
• Φροντίζουμε να ενημερώνουμε το αρχείο ΚΕΔ / HANDBOOK ΑΝΑΛΥΤΩΝ - Υπολογιστικά φύλλα Google.

ΙΙ-5 Προκαταρκτικές εργασίες για προσωπικά δεδομένα

Στα έργα που προβλέπεται να λάβει χώρα επεξεργασία δεδομένων προσωπικού χαρακτήρα, όπως αυτή ορίζεται στο άρθρο 4 του ΓΚΠΔ, θα πρέπει να ενημερώνεται ο Υπεύθυνος Προστασίας Προσωπικών Δεδομένων του αρμόδιου φορέα-Υπεύθυνου Επεξεργασίας του έργου, προκειμένου να διασφαλιστεί η συμμόρφωση με τον Γενικό Κανονισμό Προστασίας Δεδομένων (ΓΚΠΔ 2016/679/ΕΕ).

Στην ΕΔΥΤΕ υπάρχει ειδικός επί θεμάτων προσωπικών δεδομένων (DPO) τον οποίο συμβουλευόμαστε.

Φάση ΙΙΙ - Ανάλυση

Ο Αναλυτής εκπονεί τη βασική ανάλυση λαμβάνοντας υπόψη ότι η υλοποίηση θα πραγματοποιηθεί με ευέλικτες μεθοδολογίες. Επίσης, λαμβάνει υπόψη ότι το τεύχος ανάλυσης αποτελεί το πρόπλασμα για τον Καταστατικό Χάρτη.

ΤΑ. Πρόταση απλούστευσης διαδικασίας

Ολη η δράση επανεξετάζεται υπό το φως των τεσσάρων αρχών που αναφέρονται στο κεφάλαιο Βασικές αρχές σχεδιασμού ανωτέρω. Αναδεικνύονται όλα τα σημεία που αντιτίθεται στις προαναφερθείσες αρχές και προτείνονται εναλλακτικές λυσεις. Ταυτόχρονα, εξετάζονται όλες οι παράμετροι που πιθανόν να επιβαρύνουν αδίκως τη διαδικασία όπως :

• Επανυποβολή πιστοποιητικών που έχουν ήδη υποβληθεί
• Υποβολή δικαιολογητικών που πιστοποιούν πληροφορία που ήδη υπάρχει στο σύστημα
• Χρήση χειρόγραφων υπογραφών ενώ μπορεί να γίνει χρήση ψηφιακής
• Εκ του περισσού εκτυπώσεις / υποβολές έντυπων δικαιολογητικών / υπογραφές, σφραγίδες και επικυρώσεις
• Δυνατότητα ανάκτησης πληροφορίας από διαλειτουργικότητα
• Και οτιδήποτε άλλο ο αναλυτής κρίνει ότι επιβαρύνει ή περιπλέκει τη διαδικασία χωρίς πραγματικό αντίκρισμα.

Διατυπώνεται με ακρίβεια σχετική πρόταση απλούστευσης. Οπου απαιτείται συνοδεύεται από το αντίστοιχο bpmn. Τα ευρήματα μαζί με την πρόταση υποβάλλονται στην Επιτροπή Εποπτείας της Προγραμματικής με την ΓΓΨΔΑΑ ώστε να δρομολογηθούν ανάλογα.

Το τεύχος της ανάλυσης, πρέπει να περιλαμβάνει:

Τ1. Υπάρχουσα Κατάσταση

Τη διαδικασία όπως πραγματοποιείται σήμερα, εφόσον υφίσταται. Σε περίπτωση που δεν υφίσταται, γίνεται περιγραφή των αναγκών.

Ενδεικτικά καταγράφονται

• Περιγραφή υπηρεσίας
• Δικαιούχοι
• Μέσα εξακρίβωσης της ταυτότητας
• Περιγραφή διαδικασίας-βήματα (πριν/ μετά, αποτέλεσμα υπηρεσίας, υποπεριπτώσεις, εκτίμηση χρόνου)
• Απαραίτητα δικαιολογητικά
• Σχετικές διατάξεις
• Αν απαιτείται πληρωμή ή όχι
• Συσχετιζόμενο περιεχόμενο/ σχετικές υπηρεσίες

Τ2. Βασική Πρόταση

Παρατίθεται αναλυτικά η πρόταση η οποία, πέραν της περιγραφής της ψηφιοποιημένης διαδικασίας, πρέπει να περιλαμβάνει:

• Τις απαντήσεις για τα ανωτέρω δηλαδή ενδεικτικά,
  • Τρόποι ταυτοποίησης
  • Δικαιολογητικά και τρόποι ανάκτησης / ανάρτησής τους
  • E-πληρωμές που τυχόν απαιτούνται

Τ3. όλα τα απαιτούμενα στοιχεία μιας βασικής ανάλυσης, όπως

• Χρήστες και ρόλοι
• Περιγραφή dashboard και απαιτούμενες εργασίες διαχείρισης

Τ4. Διαλειτουργικότητες

Καταγράφονται όλες οι απαιτούμενες διαλειτουργικότητες του υπό κατασκευή συστήματος με άλλα συστήματα.

• Εξάρτηση από συστήματα
• Ποια Μητρώα απαιτούνται/προτείνονται να χρησιμοποιηθούν
  • Πεδία
  • Κλειδιά (απαραιτήτως)
• Χρονισμός

Τ5. Απαιτούμενες αλλαγές στη νομοθεσία

Ο Αναλυτής σε συνεργασία με το νομικό υπεύθυνο από το Υπουργείο ΨΔ, και όποιον άλλον αρμόδιο απαιτηθεί, διατυπώνει πρόταση τροποποιήσεων στη σχετική νομοθεσία, καθώς και ό,τι άλλες κανονιστικές πράξεις απαιτούνται. Η παρούσα φάση προϋποθέτει ότι έχει προηγηθεί η ανάλυση της παραγράφου ΤΒ. Απλούστευση διαδικασίας.

Τ6. Λειτουργικές και επιχειρησιακές απαιτήσεις παραγωγικής λειτουργίας

Περιγράφονται οι λειτουργικές και επιχειρησιακές απαιτήσεις για την ορθή και απρόσκοπτη παραγωγική λειτουργία σε ορίζοντα τριετίας τουλάχιστον.

Αποτυπώνονται οπωσδήποτε :

• Η ένταξη της βραχυπρόθεσμης δράσης στο gov.gr,
• Η πιθανή ένταξη της ΨΔ σε μεσοπρόθεσμο έργο.

Τ7. Απαιτήσεις Ανάλυσης Δεδομένων και σύνδεση με Δείκτες Απόδοσης

Περιγράφονται οι βασικοί δείκτες αξιολόγησης της απόδοσης του παραγόμενου αποτελέσματος της δράσης και αιτιολογείται η επιχειρηματική τους αξία. Ορίζονται οι παράμετροι που πρέπει να καταγράφονται κατά την λειτουργία του τελικού αποτελέσματος ώστε να είναι δυνατή η μέτρηση των δεικτών. Προσδιορίζονται με τη μέγιστη δυνατή λεπτομέρεια οι άξονες της ανάλυσης των δεικτών (χρόνος, φορείς, κατηγορίες κλπ) και ιδανικά τα επίπεδα λεπτομέρειας σε κάθε άξονα.

Παραδοτέο : Τεύχος ανάλυσης 
Εκτιμώμενος χρόνος: 3-4 εβδομάδες

Φάση IV - Εκπόνηση καταστατικού χάρτη

Ο Καταστατικός Χάρτης αποσκοπεί στην παροχή πληροφορίας

• προς την Επιτροπή Δράσεων της ΕΔΥΤΕ για τη λήψη απόφασης ως προς τον τρόπο υλοποίησης της ΨΔ, και
• προς οποιονδήποτε αρμόδιο για τη λήψη απόφασης για τα ζητήματα της παραγωγικής λειτουργίας.

Περιλαμβάνει:

1. Σκοπός της Δράσης

2. Στόχοι και Κριτήρια Επιτυχίας

3. Συμμέτοχοι, εμπλεκόμενοι, ενδιαφερόμενα μέρη.

4. Στελέχωση

5. Επιχειρησιακή Ανάλυση και Απαιτήσεις

   • As is

   • Που θέλουμε να πάμε

   • Ποιά είναι τα βήματα(MVPs) 1, 2,

     Η ανάλυση καταγράφει το επιχειρησιακό περιβάλλον της δράσης, σχετικές μελέτες εφόσον υπάρχουν και λειτουργούν υποβοηθητικά ή/και συμπληρωματικά, καθώς και κάθε άλλη πληροφορία που κρίνεται χρήσιμη.

6. Μελέτη Προδιαγραφών

   Λειτουργικές Προδιαγραφές για το 1ο βήμα

   Προδιαγραφές δεδομένων Μη Λειτουργικές προδιαγραφές

   Η μελέτη προδιαγραφών προτείνει συγκεκριμένο προϊόν με χαρακτηριστικά και λειτουργίες που ικανοποιούν τις απαιτήσεις, επιτυγχάνουν τους στόχους, και εξασφαλίζουν την εφικτότητα της δράσης. Το μέρος αυτό αποτελεί είτε τις προδιαγραφές για την agile διαδικασία που θα ακολουθηθεί εσωτερικά για την υλοποίηση, είτε το πρόπλασμα για το τεύχος προκήρυξης, ανάλογα του πώς θα δρομολογηθεί το έργο προς υλοποίηση.

7. Αρχιτεκτονικό Σχέδιο Υλοποίησης

   Η αρχιτεκτονική προδιαγράφει το συνολικό τεχνικό αντικείμενο της δράσης και το γενικότερο τεχνικό τοπίο στο οποίο εντάσσεται, συμπεριλαμβανομένων των εργαλείων και του αποτελέσματος της ανάπτυξης, και των εργαλείων και του αποτελέσματος της λειτουργίας.

8. Προγραμματισμός Υλοποίησης

   Ο προγραμματισμός καταγράφει χωριστά διαδοχικά εκτελεστέα βήματα υλοποίησης, εκτίμηση του χρόνου και διάρκειας εκτέλεσής τους, και εκτίμηση της χρήσης ανθρώπινων και υλικών πόρων από αυτά. Αποτελεί την αρχική έκδοση του “product backlog”.

9. Ομάδα Εργασίας

   Η ομάδα εργασίας διαμορφώνεται κατά περίπτωση και παραμένει δυναμική κατά τη διάρκεια της δράσης. Σκοπός είναι η στενή συνεργασία στελεχών, εμπλεκομένων, και ενδιαφερόμενων μερών. Αποτελεί τον πρώτο σταθμό για την εξωστρέφεια της δράσης.

   Πριν την έναρξη της υλοποίησης συντάσσεται το scrum document του έργου με βάση το υπόδειγμα.

   Σχετικό υπόδειγμα για τον Καταστατικό Χάρτη στο Παράρτημα IV.

   Παραδοτέο: Καταστατικός χάρτης 
   Εκτιμώμενος χρόνος: 1 εβδομάδα, εφόσον όλα τα ανωτέρω παραδοτέα είναι άρτια.
   

Φάση V - Software Requirement Specifications

ΕΙΣΑΓΩΓΗ

Προδιαγραφές Απαιτήσεων Λογισμικού ή SRS είναι ένα έγγραφο προδιαγραφών που επεξεργάζεται «Τι» απαιτήσεις πρέπει να πληρούνται για να ικανοποιηθούν οι επιχειρησιακές ανάγκες.

Ένα έγγραφο Προδιαγραφών Απαιτήσεων Λογισμικού (SRS) είναι ένα λεπτομερές και δομημένο έγγραφο απαιτήσεων που περιέχει τις λειτουργικές απαιτήσεις (απεικονίζει τη συμπεριφορά), μη λειτουργικές απαιτήσεις (απεικονίζει χαρακτηριστικά) και παραθέτει όλες τα use cases που το λογισμικό πρέπει να πληρεί. Το SRS είναι ένα από τα ζωτικά έγγραφα σε κάθε έργο, τεκμηριώνοντας τη συνολική διάταξη του λογισμικού, χαρακτηριστικά και ροές εργασίας.

Για να προετοιμάσει ένα SRS, ο αναλυτής πρέπει να πραγματοποιήσει συνεδρίες επεξεργασίας απαιτήσεων με τους STK , πρέπει να αναλυθούν σχολαστικά όλες οι πτυχές του λογισμικού που θα αναπτυχθεί και στη συνέχεια να καταγραφούν οι απαιτήσεις για καθεμία από αυτές. Κάθε απαίτηση που αναφέρεται σε ένα SRS θα πρέπει να πληρεί τους στόχους που αναφέρονται στην Ανάλυση.

Πότε ετοιμάζουμε το SRS

Το έγγραφο SRS συντάσσεται κατά το στάδιο «σχεδιασμού» του έργου με άλλα έγγραφα απαιτήσεων όπως το FRS, και το UCD (Use case document). Είναι ένα έγγραφο περιγραφικό και όχι τεχνικό.

Ποιο είναι το κύριο κοινό του εγγράφου SRS

• Οι διαχειριστές έργων (Project managers), ο ρόλος των οποίων συχνά ταυτίζεται με τον ρόλο του αναλυτή,επιβλέπουν την προετοιμασία του εγγράφου SRS και διασφαλίζουν ότι ευθυγραμμίζεται το περιεχόμενο του με τις καταγεγραμμένες επιχειρησιακές απαιτήσεις στο έγγραφο της ανάλυσης.
• Οι SME (subject matter experts) αξιολογούν την ορθότητα των πληροφοριών που παρουσιάζονται στο SRS
• Οι τεχνικοί - αρχιτέκτονες και ο επικεφαλής υλοποίησης του έργου είναι υπεύθυνοι για την σχεδίαση και ανάπτυξη των αναφερόμενων λειτουργιών.
• Οι STK εξετάζουν προσεκτικά και σε συνεννόηση με τον Αναλυτή (σε συνεδρία παρουσίασης του + εγγράφου ή σε ειδικό εργαστήριο) το SRS προκειμένου να διασφαλισθεί ότι απαριθμεί όλα τα χαρακτηριστικά και τις λειτουργίες του συστήματος
• Ομάδα Ανάπτυξης/Τεχνική ομάδα
• Ομάδα δοκιμών

ΠΩΣ ΝΑ ΔΗΜΙΟΥΡΓΗΣΕΤΕ ΕΝΑ ΕΓΓΡΑΦΟ SRS

Το έγγραφο SRS ως λειτουργική επέκταση του εγγράφου ανάλυσης δανείζεται πολλά τμήματα από αυτό.

1. Ρόλοι και Χαρακτηριστικά Χρήστη

Κάθε εφαρμογή ή προϊόν λογισμικού που δημιουργείται θα έχει ορισμένους χρήστες να αλληλεπιδρούν με το σύστημα. Με βάση το επίπεδο αλληλεπίδρασής τους με το σύστημα, θα έχουν διαφορετικούς ρόλους και θα πρέπει να προσδιορίζονται σε αυτήν την ενότητα, όπως στην παρακάτω μορφή :

Όνομα ρόλου: Το όνομα του ρόλου σύμφωνα με τις ανάγκες της εφαρμογής

Καθορισμός ρόλου/Τίτλος: Ο προσδιορισμός, ή ο τίτλος των χρηστών στους οποίους μπορεί αυτός ο ρόλος να ανατεθεί

Περιγραφή ρόλου: Μια σύντομη περιγραφή του ίδιου του ρόλου, των δικαιωμάτων και προνομίων του στην εφαρμογή και τα χαρακτηριστικά του χρήστη στον οποίο αυτός ο ρόλος ανατίθεται.

Συχνότητα χρήσης: Καθορισμός πόσο συχνά ο χρήστης με αυτόν τον ρόλο χρησιμοποιεί το σύστημα

2. Χαρακτηριστικά συστήματος

Η λειτουργικότητα ορίζεται ως μια επιθυμητή έξοδος(output), ή αποτέλεσμα που αναμένεται από το σύστημα μετά από μια σειρά εισόδων (inputs). Για οποιοδήποτε σύστημα με μέτριο επίπεδο πολυπλοκότητας oι λειτουργίες ομαδοποιούνται για να σχηματίσουν ένα «χαρακτηριστικό»(feature). Παρόμοια χαρακτηριστικά αποτελούν ένα module.

Κάθε μία από τις απαιτήσεις θα πρέπει να είναι ανιχνεύσιμη προς τα πίσω με ρητή αναφορά της πηγής (αναγνωριστικό απαίτησης /Business Requirement ID) σε προηγούμενα έγγραφα και θα πρέπει να οργανωθεί στην παρακάτω μορφή:

Αναγνωριστικό απαίτησης /Business Requirement ID	Module Name	Όνομα χαρακτηριστικού/Feature Name

3. Ροή διαδικασίας (Business Process Flow)

Οποιεσδήποτε λεπτομέρειες ή/και διαγράμματα που σχετίζονται με τη ροή της διαδικασίας της λύσης που προτείνεται , τη ροή δεδομένων και τη ροή πληροφοριών πρέπει να αποτυπωθούν σε σχεδιαγράμματα ροής.

Επίσης, εάν υπάρχουν πολλές διεργασίες εντός του συστήματος, τις λεπτομέρειες για το πού ταιριάζουν αυτές οι διαδικασίες, πώς συνδέονται μεταξύ τους (εάν αυτό συμβαίνει ), και για ποιο λόγο χρησιμοποιούνται πρέπει να συμπεριληφθούν.

4. Wireframes/Prototype

Ένα πρωτότυπο ή mockup αποτελεί μια αρχική έκδοση ενός προϊόντος και απεικονίζει οπτικά το τελικό προϊόν.

Θα πρέπει να συμπεριληφθεί από ένα Wireframe ή Prototype του λογισμικού για την οπτικοποίηση - εμφάνιση τυχόν δεδομένων και πλοήγησης που αντιπροσωπεύουν διαφορετικά σενάρια και προβάλλουν τη γενική εμφάνιση και αίσθηση της εφαρμογής που δημιουργείται.

Σημαντική είναι η αξιοποίηση των Prototype όσον αφορά την επιβεβαίωση- επικύρωση της κατανόησης των απαιτήσεων(requirements) από την ομάδα υλοποίησης, αλλά και από τους STK, ώστε να λάβουμε εστιασμένα σχόλια σχετικά με τη διεπαφή χρήστη και τα στοιχεία σχεδίασης( user interface and design elements).

5. Use Case Listing

Οι περιπτώσεις χρήσης πρέπει να συνθέτουν ένα «έγγραφο προδιαγραφών απαιτήσεων» που περιγράφει με ακρίβεια τον τρόπο με τον οποίο ένας χρήστης θα αλληλεπιδράσει με το σύστημα που αναπτύσσεται, μέσω μιας ροής γεγονότων.

Αυτή η ενότητα θα πρέπει να περιέχει μια λίστα με όλες τις περιπτώσεις χρήσης , που υποτίθεται ότι προετοιμάστηκε κατά τη φάση ανάλυσης του έργου. Κάθε περίπτωση χρήσης πρέπει να συμπληρώνεται με μια σύντομη περιγραφή των λειτουργιών, των σεναρίων και των ροών που περιέχονται σε καθένα από αυτά.

**ΩΡΑ ΓΙΑ ΣΥΜΒΟΥΛΕΣ

1. Γράφετε προτάσεις σύντομες και κατανοητές

Η παραδοσιακή έρευνα λέει ότι ένας άνθρωπος μπορεί να κρατήσει 7 αντικείμενα στη μνήμη του κάθε φορά, και οι τελευταίες μελέτες δείχνουν ότι αυτός ο αριθμός έχει μειωθεί σε 4. Έτσι, εάν χρησιμοποιείτε υπερβολικά μεγάλες προτάσεις, αυξάνετε τις πιθανότητες οι ενδιαφερόμενοι να χάνουν το νόημα και να μην κατανοούν το έγγραφό σας SRS.

Έτσι, κάντε τις προτάσεις σας σύντομες και τεμαχίστε τις πληροφορίες σε πολλές προτάσεις, έτσι και οι devs θα λαμβάνουν μία απαίτηση την φορά, και θα είναι πιο εστιασμένοι .

2. Αποφύγετε την ασάφεια

Θα ήταν καλύτερο να προσπαθήσετε να είστε όσο το δυνατόν πιο συγκεκριμένοι στις απαιτήσεις.

Αποφύγετε τη χρήση λέξεων όπως: περίπου, κλπ., μερικές, μερικές φορές, συνήθως, τα περισσότερα, κυρίως,συνήθως, και μπορεί.

Επίσης, βεβαιωθείτε ότι αποφεύγετε τις επαναλήψεις - όπου είναι δυνατόν - και προσέχετε την χρήση αντιφατικών εννοιών.

Τα ευκρινή έγγραφα απεικονίζουν καθαρή σκέψη και μεθοδικότητα, δεξιότητες που είναι αναπόσπαστες από τον ρόλο ενός αναλυτή.

*Ας δούμε ένα μικρό παράδειγμα σχετικά με τις Ακριβείς απαιτήσεις:

Ο χρήστης μπορεί να αλλάξει τον κωδικό πρόσβασής του κάνοντας κλικ στον σύνδεσμο αλλαγή κωδικού πρόσβασης στη σελίδα σύνδεσης και γράφοντας το καταχωρημένο email του στην ακόλουθη οθόνη...

Στη συνέχεια, το σύστημα θα στείλει ένα μήνυμα μέσω email στο καταχωρημένο του email, στο οποίο θα αναφέρει <κάντε κλικ εδώ για να αλλάξετε τον κωδικό πρόσβασης σας >,στην συνέχεια θα φέρει τον χρήστη σε μια νέα οθόνη. Σε αυτή τη νέα οθόνη, ο χρήστης μπορεί πλέον αλλάξει τον κωδικό πρόσβασης του.

Τα βήματα που πρέπει να γίνουν για την αλλαγή του κωδικού πρόσβασης είναι:

• Κάντε κλικ στο σύνδεσμο «Αλλαγή κωδικού πρόσβασης» στη σελίδα «Εισόδου».
• Στην συνέχεια πηγαίνει σε μια οθόνη «Επιβεβαίωσης» όπου το καταχωρημένο αναγνωριστικό email του χρήστη πρέπει να εισαχθεί
• Το σύστημα στέλνει έναν σύνδεσμο «Επαναφορά κωδικού πρόσβασης» στο καταχωρημένο αναγνωριστικό email (που έχει εισαχθεί στο προηγούμενο βήμα)
• Κάνοντας κλικ σε αυτόν τον σύνδεσμο θα μεταφερθεί ο χρήστης στην οθόνη «Αλλαγή κωδικού πρόσβασης».
• Ο νέος κωδικός πρόσβασης μπορεί να οριστεί σε αυτήν την οθόνη

Παράδειγμα πλήρους απαίτησης:

Ελλιπής	Πλήρης
Κατά την επαναφορά ενός κωδικού πρόσβασης, θα πρέπει να μην είναι ίδιος με προγενέστερους κωδικούς πρόσβασης. Επίσης, οι σχετικές οδηγίες για τον κωδικό πρόσβασης πρέπει να ακολουθούνται	Κατά την επαναφορά ενός κωδικού πρόσβασης, ο νέος κωδικός θα πρέπει να μην είναι ίδιος με κάποιον από τους τελευταίους 5 κωδικούς που έχουν χρησιμοποιηθεί . Επίσης, ο κωδικός πρόσβασης πρέπει να αποτελείται από τουλάχιστον 8 χαρακτήρες με κατ’ ελάχιστο έναν αριθμητικό και έναν ειδικό χαρακτήρα.

Παράδειγμα ανέφικτης απαίτησης:

Με έναν διακομιστή εφαρμογών, το εργαλείο διαχείρισης χρηστών θα πρέπει να εξυπηρετεί 2 εκατομμύρια ταυτόχρονους χρήστες και ο χρόνος απόκρισης δεν πρέπει να είναι μεγαλύτερος από 1 δευτερόλεπτο.

Παράδειγμα του τρόπου με τον οποίο οι απαιτήσεις πρέπει να καταγράφονται:

Περιγραφή	Παράδειγμα
Η διαδικτυακή εφαρμογή θα πρέπει να έχει πολυγλωσσική υποστήριξη	Η διαδικτυακή εφαρμογή θα πρέπει να υποστηρίζει Αγγλικά, Γαλλικά και Γερμανικά
Η διεπαφή χρήστη θα πρέπει να λειτουργεί στα κυριότερα προγράμματα περιήγησης	Η διεπαφή χρήστη θα πρέπει να λειτουργεί στα προγράμματα περιήγησης chrome , safari , firefox
Σε περίπτωση λανθασμένων διαπιστευτηρίων, το σύστημα θα πρέπει να δώσει ένα «σωστό» μήνυμα προειδοποίησης	Σε περίπτωση λανθασμένων διαπιστευτηρίων, το σύστημα θα πρέπει να εμφανίζει ένα μήνυμα ειδοποίησης «Μη έγκυρα διαπιστευτήρια. Σας παρακαλούμε πολύ ελέγξτε το email/κωδικό που έχετε εισαγάγει.

SRS ΠΕΡΙΕΧΟΜΕΝΑ:

Λεπτομέρειες έκδοσης εγγράφου (versioning details)

Αρ. έκδοσης	Ημερομηνία	Ενέργεια	Υπέυθυνος Αλλαγής	Υπεύθυνος Έγκρισης
---	---	---	---	---

1. Εισαγωγή

Αυτή η ενότητα παρέχει μια επισκόπηση του εγγράφου SRS και περιγράφει συνοπτικά το επιχειρησιακό πρόβλημα που επιλύεται, το εύρος- έκταση των δραστηριοτήτων του έργου, συμπεριλαμβανομένων των STK που εμπλέκονται στο έργο.

1.1 Ορισμοί και συντομογραφίες

Η έννοια και η περιγραφή οποιασδήποτε ορολογίας για συγκεκριμένο έργο, τεχνικές συντομογραφίες και επιχειρησιακά ακρωνύμια που χρησιμοποιούνται στο έγγραφο πρέπει να αναφέρονται εδώ.

Ακρωνύμιο	Περιγραφή-Ορισμός
---	---
---	---

1.2 Αναφορές

Καταγράψτε οποιοδήποτε από τα άλλα έγγραφα αναφοράς που αναφέρονται στο έγγραφο.

Μπορούν να περιλαμβάνονται έγγραφα στο κοινόχρηστο αποθετήριο του έργου , URL κ.α.

Στοιχεία εγγράφου αναφοράς	Τοποθεσία
Όνομα	<Αντίστοιχη τοποθεσία στο δίκτυο ή κοινόχρηστο αποθετήριο έργου>
---	---

2.Περιγραφή σε high level

2.1 Ιστορικό

Αυτές οι πληροφορίες μπορούν να ληφθούν από τον χάρτη του έργου, ή τα έγγραφα του οράματος του έργου και περιέχουν τα ακόλουθα στοιχεία:

• Λεπτομέρειες για το υπάρχον επιχειρησιακό περιβάλλον
• Ζητήματα και προβλήματα που πρέπει να αντιμετωπιστούν
• Τί είδους λύση εξετάζεται για την επίλυση αυτών των προβλημάτων (σύντομη επεξήγηση)
• Ο στόχος πίσω από τη δημιουργία του συγκεκριμένου λογισμικού

2.2 Project scope

Αυτή η ενότητα περιέχει μια περίληψη του τι περιλαμβάνεται και τι όχι στο πεδίο των δραστηριοτήτων αυτού του έργου. Οι απαιτήσεις αυτής της ενότητας θα πρέπει να είναι συγκεκριμένες, σαφείς και ξεκάθαρες , ενώ ταυτόχρονα να είναι εφικτές.

• In Scope: Παρέχετε μια σύνοψη υψηλού επιπέδου για το τι πρέπει να συμπεριληφθεί (στο πεδίο εφαρμογής) για την ολοκλήρωση του έργου και θα πρέπει να θεωρείται μέρος των του έργου. Όλα τα χαρακτηριστικά, οι λειτουργίες και οι ενότητες που είναι «εντός πεδίου εφαρμογής» καθορίζουν τα συνολικά όρια του έργου. Θα πρέπει να δίνεται προσοχή σε αυτήν την ενότητα και μόνο το «Τι» της λύσης θα πρέπει να περιλαμβάνεται εδώ (και όχι το «Πώς»).

  Επίσης, τα στοιχεία αυτής της ενότητας θα πρέπει να υποβληθούν σε ενδελεχή
  

  επανεξέταση (τόσο από εσωτερικούς όσο και από εξωτερικούς STK), καθώς θα γίνεται αναφορά σε αυτά σε περίπτωση συζητήσεων, ή και διαφωνιών σχετικά με αιτήματα αλλαγής.

• Out of Scope: Παρέχετε μια σύνοψη υψηλού επιπέδου για το τι δεν πρέπει να λαμβάνεται υπόψη (εκτός πεδίου εφαρμογής) για την ολοκλήρωση του έργου και τι δεν πρέπει να αποτελεί μέρος του τρέχοντος πεδίου εφαρμογής του έργου (αυτές οι απαιτήσεις μπορεί να αποτελούν μέρος μελλοντικών φάσεων του έργου).]

2.3 Ρόλοι και Χαρακτηριστικά Χρηστών

Κάθε εφαρμογή, ή προϊόν λογισμικού που δημιουργείται θα έχει ορισμένους χρήστες που θα αλληλεπιδρούν με το σύστημα. Με βάση το επίπεδο αλληλεπίδρασής τους με το σύστημα, θα έχουν διαφορετικούς ρόλους και θα πρέπει να προσδιορίζονται σε αυτήν την ενότητα στην παρακάτω μορφή:

• Όνομα ρόλου
• Προσδιορισμός χρηστών που θα έχουν τον συγκεκριμένο ρόλο
• Περιγραφή ρόλου
• Συχνότητα χρήσης συστήματος

2.4 Περιορισμοί

Οι περιορισμοί ορίζονται ως οποιοιδήποτε «παράγοντες» που σηματοδοτούν τα όρια γύρω από τις λειτουργίες του έργου, ή «εξαρτήσεις» που περιγράφουν τον τρόπο με τον οποίο θα εκτελεστούν οι δραστηριότητες του έργου. Μπορεί να υπάρχουν διάφοροι παράγοντες που θα μπορούσαν να αποτελούν περιορισμό του έργου, για παράδειγμα:

• Σχεδίαση διεπαφής χρήστη: Ένα σχέδιο διεπαφής χρήστη που είναι δύσκολο να επιτευχθεί τεχνικά
• Αναθεώρηση κώδικα: Οι αναθεωρήσεις κώδικα που δεν μπορούσαν να αποφευχθούν, αλλά προφανώς επιβραδύνουν τον ρυθμό ανάπτυξης των εφαρμογών
• Ανθρώπινοι πόροι: Απόκτηση ειδικευμένων/εξειδικευμένων πόρων για την εργασία στο έργο, ή ένα σταθερό μέγεθος της ομάδας ανάπτυξης
• Νομικά: Ορισμένοι νόμοι, ή κανονισμοί που περιορίζουν τις δραστηριότητες του έργου
• Διαδικασία οργάνωσης: Διαδικασίες που ορίζονται σε οργανωτικό επίπεδο και πρέπει να τηρούνται
• Ποιότητα: Ορισμένες απαιτήσεις που πρέπει να πληρούνται σχετικά με την ποιότητα, ή τη συμμόρφωση
• Τεχνική: Οποιαδήποτε απαίτηση που δεν είναι δυνατό να επιτευχθεί λόγω τεχνικών περιορισμών
• Διάρκεια: Ολοκλήρωση μιας συγκεκριμένης δραστηριότητας μέσα σε μια καθορισμένη χρονική διάρκεια
• Προϋπολογισμός: Ο προϋπολογισμός του έργου είναι ένας άλλος κοινός περιορισμός που ελέγχει το ποσό των χρημάτων που θα μπορούσαν να δαπανηθούν και έτσι θέτει ένα όριο σε πολλές λειτουργίες του έργου.

2.5 Εξαρτήσεις

Συνήθως, πολλές δραστηριότητες του έργου εξαρτώνται η μία από την άλλη , οι σημαντικές πρέπει να παρατίθενται εδώ.

• Εξαρτήσεις που βασίζονται σε πόρους
• Εξαρτήσεις που βασίζονται σε προγενέστερες εργασίες
• Εξαρτήσεις από άλλα συστήματα

3.Λειτουργικές προδιαγραφές-απαιτήσεις (Functional Requirements)

Οι λειτουργικές απαιτήσεις περιγράφουν τις λειτουργίες, τις δυνατότητες και τις δραστηριότητες που πρέπει να είναι σε θέση να εκτελεί ένα σύστημα. Αυτή η ενότητα περιέχει μια αναλυτική αναφορά απαιτήσεων για να μπορέσει ο αναγνώστης να τις κατανοήσει καλύτερα και να περιλαμβάνει τις συγκεκριμένες συμπεριφορές και χαρακτηριστικά που αναμένονται από την εφαρμογή ή το λογισμικό που αναπτύσσεται. Επιπλέον, εδώ θα πρέπει να συμπληρωθούν διαγράμματα ροής, Wireframes, Λίστα περιπτώσεων χρήσης(use case list) ή άλλοι παρόμοιοι τύποι πληροφοριών.

3.1 Χαρακτηριστικά συστήματος (System Features)

Μια λειτουργικότητα ορίζεται ως μια επιθυμητή έξοδος(output), ή αποτέλεσμα που αναμένεται από το σύστημα μετά από μια (σειρά) εισόδου(input). Για οποιοδήποτε σύστημα με μέτριο επίπεδο πολυπλοκότητας, τέτοιες λειτουργίες ομαδοποιούνται για να σχηματίσουν ένα «χαρακτηριστικό» (feature) - παρόμοια χαρακτηριστικά αποτελούν μια «μονάδα»(module).

Κάθε μία από τις απαιτήσεις θα πρέπει να είναι ανιχνεύσιμη προς τα πίσω, αναφέροντας ρητά την πηγή της (αναγνωριστικό απαίτησης- business requirement id)) σε προηγούμενα έγγραφα και θα πρέπει να οργανωθεί στην παρακάτω μορφή:

Ενότητα Α: Περιγραφή της ενότητας

Χαρακτηριστικό 1: Περιγραφή του χαρακτηριστικού

Λειτουργικότητα α

Λειτουργικότητα β

..

..

Λειτουργικότητα n

Χαρακτηριστικό 2:

..

..

Χαρακτηριστικό n:

| Αναγνωριστικό απαίτησης /Business Requirement ID | Module Name | Όνομα χαρακτηριστικού/Feature Name | |----|----|----| | | | | | |

3.2 Ροή Επιχειρηματικών Διαδικασιών (Business Process Flow)

Τις περισσότερες φορές, οι εφαρμογές λογισμικού ακολουθούν μια ιεραρχική/διαδοχική ροή γεγονότων που ξεκινούν μετά την εκτέλεση μιας συγκεκριμένης ακολουθίας εισόδων(inputs).

Οποιεσδήποτε τέτοιες λεπτομέρειες και/ή διαγράμματα που σχετίζονται με τη ροή της διαδικασίας λύσης, τη ροή δεδομένων και τη ροή πληροφοριών θα πρέπει να εμφανίζονται εδώ.

Επίσης, εάν υπάρχουν πολλές διεργασίες εντός του συστήματος, θα πρέπει να περιλαμβάνονται οι λεπτομέρειες σχετικά με το πού ταιριάζουν αυτές οι διεργασίες, πώς συνδέονται μεταξύ τους (εάν συμβαίνει αυτό) και για ποιο αποτέλεσμα χρησιμοποιούνται.

3.3 Wireframes/Prototype

3.4 Απαιτήσεις διεπαφής χρήστη (User Interface Requirements)

3.5 Use Case Listing

4.Μη λειτουργικές προδιαγραφές -απαιτήσεις Non-Functional Requirements

Τα «λειτουργικά χαρακτηριστικά», ή οι μη λειτουργικές απαιτήσεις του συστήματος ,όπως ο χρόνος απόκρισης του συστήματος, η απόδοση, η επεκτασιμότητα και η χρηστικότητα περιλαμβάνονται εδώ.

Ενώ προσπαθείτε να καταλάβετε τι είδους απαιτήσεις πρέπει να υπάρχουν εδώ, προσπαθήστε να τις δείτε ως «ιδιότητες» που θα έπρεπε να έχει το σύστημα.

Αυτή η ενότητα θα πρέπει να περιέχει μόνο τις λεπτομέρειες γύρω από την κάθε απαίτηση χωρίς να διευκρινίζει τον τρόπο με τον οποίο υποτίθεται ότι πληρούνται(ικανοποιούνται) αυτές οι απαιτήσεις

4.1 Απαιτήσεις απόδοσης (Performance Requirements)

Παραθέστε εδώ όλα τα χαρακτηριστικά και τα χαρακτηριστικά που σχετίζονται με την απόδοση της εφαρμογής/λογισμικού. Όλες αυτές οι λεπτομέρειες θα βοηθήσουν την τεχνική ομάδα(devs) να πραγματοποιήσει τον προγραμματισμό – πρόβλεψη (capacity planning) για τους διακομιστές, το υλικό (hardware)και τα στοιχεία λογισμικού(software components) του συστήματος που αναπτύσσεται.

Θα πρέπει να περιλαμβάνει πληροφορίες σχετικά με :

• Λεπτομέρειες σχετικά με το μέσο φορτίο (average load )στο σύστημα (αριθμός χρηστών)
• Χρόνος απόκρισης συστήματος (ελάχιστος αποδεκτός και μέγιστος)
• Χρόνος επαναφοράς του συστήματος
• Διακίνηση (Throughput) βέλτιστης απόδοσης
• Μέγιστος (maximum /peak ) φόρτος εργασίας (workload )που πρέπει να χειριστεί το σύστημα
• Επεκτασιμότητα (ικανότητα ελέγχου του πρόσθετου φόρτου εργασίας εάν προστεθούν επιπλέον υλικό(hardware) και επεξεργαστές
• Οποιεσδήποτε παραδοχές σχετικά με την απόδοση
• Καθορισμός ορίων για το χρονικό διάστημα που είναι ανεκτό για διαφορετικούς τύπους σφαλμάτων να παραμένουν μη ανιχνεύσιμοι (ανίχνευση και πρόληψη σφαλμάτων)
• Πόσο καιρό θα είναι διαθέσιμο το σύστημα (όλη την ημέρα ή σε συγκεκριμένες ώρες;)
• Πώς θα μάθουν οι χρήστες για τη μη διαθεσιμότητα;
• Τυχόν εναλλακτικές δραστηριότητες που απαιτούνται σε περίπτωση μη διαθεσιμότητας

4.2 Απαιτήσεις χρηστικότητας (Usability Requirements)

Οι εφαρμογές και τα προϊόντα πρέπει να είναι εύκολα κατανοητά και αποτελεσματικά στη χρήση. Οποιεσδήποτε απαιτήσεις σχετικά με τη χρήση του υπό ανάπτυξη συστήματος θα πρέπει να αναφέρονται εδώ. παραδείγματα περιλαμβάνουν:

• Ευκολία στη χρήση
• Αποτελεσματικότητα χρήσης
• Ταχύτητα λειτουργίας
• Διαισθητικότητα/κατανοητικότητα- αντίληψη χρήσης
• Ικανοποίηση

4.3 Απαιτήσεις ασφαλείας(Security Requirements)

Αυτές οι απαιτήσεις καθορίζουν πόσο ασφαλή (από ανήθικους και μη επιτρεπόμενους χρήστες) είναι η εφαρμογή και το δίκτυό της, οι διακομιστές, τα λειτουργικά συστήματα και οι υποδομές τους και εξαρτώνται από το είδος του λογισμικού, ή της εφαρμογής που κατασκευάζεται και τα δεδομένα που περιέχει.

Ο αναλυτής θα πρέπει να αφιερώσει πολύ χρόνο με το τεχνικό τμήμα & το τμήμα πληροφορικής του πελάτη.... και να προσπαθήσει να λάβει όλες αυτές τις λεπτομέρειες. Ωστόσο, σε κάθε περίπτωση θα πρέπει να προταθούν οι τυπικές απαιτήσεις ασφάλειας που ισχύουν στον κλάδο, όπως:

• Έλεγχος ταυτότητας χρήστη
• Εξουσιοδότηση χρήστη
• Πρόσβαση δεδομένων
• Έλεγχος πρόσβασης
• Ακεραιότητα δεδομένων
• Δοκιμή ευπάθειας (σε hacking).

4.4 Απαιτήσεις Εκπαίδευσης(Training Requirements)

Κάθε είδους απαίτηση όπου οι χρήστες πρέπει να εκπαιδεύονται σχετικά με τη χρήση του συστήματος θα πρέπει να περιγράφεται εδώ.

Περιλαμβάνει:

• Εκπαίδευση τελικού χρήστη
• Εκπαίδευση του προσωπικού υποστήριξης
• Προετοιμασία εκπαιδευτικών εγχειριδίων/οδηγών/βίντεο

4.5 Απαιτήσεις ανάκτησης (Recovery Requirements)

Αυτές είναι οι απαιτήσεις που διασφαλίζουν ότι όλες οι υπηρεσίες λειτουργούν ακόμη και σε περίπτωση φυσικών καταστροφών και απρόβλεπτων συνθηκών (ονομάζεται επίσης Επιχειρησιακή Συνέχεια).

Θα πρέπει να περιέχει:

• Τι θα χαρακτηριστεί ως καταστροφή (ο ορισμός της);
• Δημιουργία σχεδίου αποκατάστασης από καταστροφές (DR/disaster recovery): Σχέδιο που καθορίζει πώς θα αποκατασταθούν οι υπηρεσίες σε περίπτωση καταστροφής
• Recovery Point Objective (RPO): Αποδεκτός όγκος δεδομένων που μπορεί να χαθεί σε περίπτωση καταστροφής
• Στόχος Χρόνου Ανάκτησης (RTO Recovery Time Objective (RTO)): Αποδεκτό χρονικό διάστημα που η εφαρμογή ή/και οι υπηρεσίες θα διακοπούν σε περίπτωση καταστροφής
• Ποια είναι τα όρια ανοχής υποβάθμισης της απόδοσης σε περίπτωση καταστροφής;
• Πόσο συχνά χρειάζεται να εκτελείται ένα εικονικό πλάνο DR: <<Η δοκιμή ανάκαμψης από καταστροφές είναι μια άσκηση πολλαπλών βημάτων του σχεδίου αποκατάστασης καταστροφών (DRP)που έχει σχεδιαστεί για να διασφαλίζει ότι τα συστήματα τεχνολογίας πληροφοριών (IT) θα αποκατασταθούν εάν συμβεί μια πραγματική καταστροφή.>>

5.Απαιτήσεις ποιοτικού ελέγχου και δοκιμών (Quality Control and Testing Requirements)

Αυτή η ενότητα περιέχει όλες τις απαιτήσεις και τις δραστηριότητες που είναι απαραίτητες για να διασφαλιστεί ότι η ποιότητα της εφαρμογής είναι υψηλών προδιαγραφών και παραμένει εντός των καθορισμένων ορίων κατά τη διάρκεια του κύκλου ζωής ανάπτυξης του έργου.

Αυτές οι δραστηριότητες περιλαμβάνουν, αλλά δεν περιορίζονται σε:

• Καθορισμό της έκτασης των δοκιμών που απαιτούνται
• Προσδιορισμό της φύσης της δοκιμής (χειροκίνητη ή αυτοματοποιημένη)
• Καθορισμό του τύπου της δοκιμής που θα εκτελεστεί (λειτουργική, απόδοση, ασφάλεια, κλπ)
• Τεχνικές δοκιμών, μεθοδολογίες και στρατηγικές που θα χρησιμοποιηθούν
• Συχνότητα των δραστηριοτήτων δοκιμών
• Τι τυπολογία τεκμηρίωσης θα ετοιμαστεί έναντι των δοκιμών
• Μετρήσεις που πρέπει να ληφθούν για να γνωρίζετε την πρόοδο των δοκιμών στο έργο
• Οποιαδήποτε άλλη απαίτηση σχετική με τις δοκιμές

5.1 Συντήρηση συστήματος και πρόσθετες απαιτήσεις (System Maintenance and Additional Requirements)

Απαιτήσεις που δεν ταιριάζουν σε καμία από τις ενότητες που ορίζονται παραπάνω θα πρέπει να μπουν εδώ.

Μερικές από τις ενότητες που θα μπορούσαν να συμπεριληφθούν εδώ είναι:

• Απαιτήσεις διαχείρισης έργου: Οποιεσδήποτε απαιτήσεις σχετίζονται με τον τρόπο διαχείρισης, παρακολούθησης, ή ελέγχου του πλήρους έργου (ή ορισμένων συγκεκριμένων τμημάτων του) θα πρέπει να εμφανίζονται εδώ.
• Συντήρηση συστήματος: Οποιεσδήποτε απαιτήσεις σχετίζονται με τον τρόπο συντήρησης του συστήματος μετά την ολοκλήρωσή του και τη λειτουργία του
• Απαιτήσεις αποθήκευσης: Οποιεσδήποτε απαιτήσεις σχετικά με τον τρόπο αποθήκευσης, διαχωρισμού ή ομαδοποίησης των δεδομένων (ιδιαίτερα σε εφαρμογές δεδομένων ,ή επεξεργασίας μεγάλων εφαρμογών)
• Απαιτήσεις πόρων/εργατικού δυναμικού: Ειδικές σημειώσεις σχετικά με τον τύπο, τα επίπεδα εμπειρίας, την ικανότητα των πόρων που πρέπει να χρησιμοποιηθούν για την ανάπτυξη της εφαρμογής

6. Ρίσκα

Οποιαδήποτε αβέβαια γεγονότα, ή παράγοντες που αποτελούν απειλή για την επιτυχή υλοποίηση των δραστηριοτήτων του έργου ταξινομούνται ως κίνδυνος. Αυτή η ενότητα θα πρέπει να περιέχει οποιονδήποτε από τους αρχικούς κινδύνους που προβλέπονται με βάση όσα είναι γνωστά για το έργο μέχρι σήμερα.

Μερικοί από τους τομείς από τους οποίους θα μπορούσε να προέλθει ο κίνδυνος είναι:

• Διαθεσιμότητα πόρων/ειδικευμένων πόρων
• Λανθασμένες/υπερβολικά αισιόδοξες εκτιμήσεις
• Οι υποθέσεις που τείνουν να είναι ψευδείς
• Ασαφείς/κακώς καθορισμένες απαιτήσεις
• Καμπύλη εκμάθησης
• Έλλειψη διαχείρισης αλλαγών (ειδικότερα πρόβλεψης!)
• Οι απαιτήσεις που δεν εξετάζονται/υπογράφονται
• Αόριστες ή ανεπαρκείς επικοινωνίες έργου
• Τεχνικοί κίνδυνοι/κίνδυνοι εφαρμογής]

7.Κριτήρια Ολοκλήρωσης

Είναι σημαντικό να ορίζεται η «πληρότητα» από την οπτική γωνία του έργου και τα κριτήρια που πρέπει να πληρούνται για να επισημανθεί η ολοκλήρωση των εργασιών του έργου , αυτά περιγράφονται λεπτομερώς σε αυτήν την ενότητα.

Για παράδειγμα:

• Συμμόρφωση του αναπτυγμένου λογισμικού με τις αντίστοιχες τεκμηριωμένες απαιτήσεις
• Δοκιμή λειτουργικότητας (Unit testing of functionality)
• Δραστηριότητες αναθεώρησης κώδικα που πρέπει να πραγματοποιηθούν
• Δοκιμή συστήματος (System testing)
• Integration testing
• Αριθμός επιτρεπόμενων ελαττωμάτων/προβλημάτων δυσλειτουργιών

Φάση VI - Τεύχος διαγωνισμού

Εφόσον η Επιτροπή Δράσεων κρίνει ότι η βραχυπρόθεσμη δράση δεν μπορεί να υλοποιηθεί εσωτερικά στο ΕΔΥΤΕ, ο Αναλυτής εκπονεί το σχετικό RFP που συμπεριλαμβάνει και τους πίνακες συμμόρφωσης.

Παραδοτέο: RFP
Εκτιμώμενος χρόνος: 1 εβδομάδα.